Conversation
Add the apis to BrickMain
lsmor
left a comment
lsmor
left a comment
There was a problem hiding this comment.
I am not able to fully review this as the code is way more complex than my knowledge 😅 . My understading is:
- Menus are defined by two parallel datatypes The "Fields" + "Options", and then this
GenericMenuthing which I barely understand... Instead of Having "Options" + list of fields as before. - Existentials are hidden behind TypeClasses + Data.Some if I understand correctly.
- I don't get the Overlays part. AFAIU,
brickdispatches events to the frontward layers, so there is no need to pass events to the "child"/overlayed widget... but maybe I got this wrong
|
@lsmor Unfortunately the changes here did become big and complex. They can be seen as two major parts The first is the I guess the main thing to review here is how the new design is being used and how more features/widgets could be added. In this commit I have implemented a confirmation prompt for pre-install messages using this new design. Implementing this in the earlier design would have been far more complex. |
2 participants
Removes use of existentials. fixes Remove existential types in TUI #1217
Makes use of GHC.Generics to take care of the Menu boilerplate
Improves the structure of code as each widget now need to implement the instance of BaseWidget, which captures the two essential parts, rendering and event handling.
The structure of the widget state matches directly to the "tree" structure of widgets. And the use of enums, like
Mode, have been removed.The input fields are more generic and we can nest them, like
EditInputis being used insideSelectInputThe value of input fields can be modified like this
The child widget does not modify the state of parent (as it was earlier being done via lens)
The 'quit' key handling logic is now mostly part of the
BasicOverlayabstraction, and has been removed from the event handlers of individual widgets.We can even do nesting of
GenericMenu, in case we want to make fancy sub-menus